Using packet data transmission techniques, information is sent between nodes in the form of data packets. Packets can be of various sizes and, for some types of communication, a complete content may be sent as one single packet. This may be the case, for example, of the act of sending a web page from a web server to a web browser, if the page is simple and has a small content. For a large number of applications, contents need to be fragmented into multiple packets that are amenable for packet transmission, for reasons that are well-known in the art. A receiver of such contents reassembles packets after receiving them.
Various servers, routers and hosts may be capable of sending, receiving or transmitting packets of various sizes. While a sender may be capable of producing very large packets, a destination of those packets or some intervening nodes may only be capable of handling smaller packets. According to the Internet Protocol version 4 (IPv4), when a sender sends a packet of a given size towards a receiver, if an intermediate router cannot carry the packet further because of its size, the intermediate router may fragment the packet into two or more smaller packets, in which case the packets are reassembled at their destination. According to the Internet Protocol version 6 (IPv6), intermediate routers are not allowed to fragment packets. The sender of a content must therefore determine, a priori, what may be an acceptable packet size along a path leading to a destination of the packet. Of course, a sender could fragment a content into very small packets and thereby ensure that the packet size is acceptable to any node towards the destination. However, such an approach would be very inefficient in using network resources.
The Internet Engineering Task Force (IETF) has published a Request For Comments (RFC) number 1981, entitled “Path MTU Discovery for IP version 6”, wherein MTU stands for Maximum Transmission Unit. The RFC describes a technique for discovering a maximum allowable packet size—the MTU—that can be allowed on a given path or link. The method involves sending from a data source, on the path of interest, a probe packet, preferably of a large size, and determining whether a Packet Too Big message is received. This message, sent by one of the nodes along the path to indicate that the packet was dropped because of its size, carries a MTU for the node having sent it. The data source then sends another probe packet, sized according to the received MTU value. That new probe packet may arrive at its destination, or may be blocked at some further point along the path, in which case that point sends another Packet Too Big message with another, lower MTU value. The process continues until a probe packet of an acceptable size reaches its destination, in which case no Packet Too Big message is returned to the sender. Thereafter, the data source has learned the MTU for the path and can use its value for sending packets along that path.
For multicast services, a data source needs to send packets towards multiple destinations, oftentimes through distinct paths. The Path MTU Discovery method of RFC 1981 does not provide good performance when a number of MTU sizes applicable to several paths need to be known for purposes of multicast services. This is because the data source needs to obtain MTU values for each of a number of multicast paths individually, and then select the lowest of all the discovered MTU values. This requires a multiplicity of probe packets being sent along all multicast paths. This is a slow process that delays startup of a multicast service and that consumes a lot of valuable bandwidth.